View AN4276_8134066.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

september 2013 docid024408 rev 2 1/21 AN4276 application note ecc management on spc560x introduction this document describes error correction code (ecc) management and implementation on spc560x microcontroller family. it describes both hardware and software aspects linked to the ecc mechanism used to protect content of memories. it starts with an overview of ecc protection and than it jumps to more detailed hardware ecc fault management and how it is implemented in the microcontroller. the hardware notification on one side is important but not enough to correctly manage memory content faults in the application. that is why this note takes closer look on software aspects in its second part. www.st.com
contents AN4276 2/21 docid024408 rev 2 contents 1 ecc overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 ecc principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 number of check bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 ecc on spc560x microcontroller family . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 ram ecc implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 code and data flash memory ecc implementation . . . . . . . . . . . . . . . . . 7 2.3 ecsm module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3 ecc error hardware exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 ecsm module interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 core exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4 ecc exception handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 ram ecc error action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 code flash ecc error action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3 data flash ecc error action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.1 continue with successive instruction of the read function . . . . . . . . . . . 12 4.3.2 continue from known address in the read function . . . . . . . . . . . . . . . . 13 4.4 clearing error flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5 application software notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1 ram memory checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 operating system (os) exception handling . . . . . . . . . . . . . . . . . . . . . . . 15 5.3 flash memory drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3.1 check ecc immediately after each read access . . . . . . . . . . . . . . . . . 17 5.3.2 check ecc after whole data buffer is read . . . . . . . . . . . . . . . . . . . . . . 17 5.3.3 low level exception handler link to the driver ecc check . . . . . . . . . . . 18 appendix a document references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
docid024408 rev 2 3/21 AN4276 list of tables list of tables table 1. sec-ded code - number of check bits needed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 table 2. sram timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 table 3. flash codes with the same syndrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 table 4. ecsm module register set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 table 5. non-correctable ecc exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0 table 6. document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
list of figures AN4276 4/21 docid024408 rev 2 list of figures figure 1. ecc block scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 figure 2. ecsm interrupt generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 figure 3. example of core exception flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 figure 4. general ivor2/3 handler software flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 figure 5. pseudo-code for next instruction handler flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 figure 6. instruction primary opcode decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 figure 7. pseudo code for known address jump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 figure 8. os exception handling with user hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 figure 9. example of immediate ecc check during read function . . . . . . . . . . . . . . . . . . . . . . . . . . 17 figure 10. example of ecc check after whole buffer is read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 figure 11. example of low level link to the driver ecc check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
docid024408 rev 2 5/21 AN4276 ecc overview 1 ecc overview error correction codes, ecc, are known techniques to protect data information against single or multiple bit errors. sram memories represent main field of ecc usage, where soft induced bit flips errors are common and where these problems increase with processes going to submicron ranges. ecc protection is one of the highly recommended measures of memory protection in high reliable and safety systems. there are several conventional algorithms used for ecc protection, single-error-correcting (sec) hamming code, single-error-correcting-double-error-detecting (sec-ded) modified hamming, or sec-ded hsiao code. all of these algorithms are based on principle of extending information bits with so called check bits in a way that bit error on reception is identified and corrected in case of one bit error or detected in case of two errors. 1.1 ecc principle set of information symbols (data), where any bit error in one symbol leads to another valid, but wrong symbol, is transformed to another set of code words by extending information bits with check bits. the size of new code set is higher than the size of original one. it gives an option to map original information symbols to code words with specific characteristic like hamming distance specifying number of bits in which these code words differ. 1.2 number of check bits there is a minimum number of check bits that are needed for sec-ded protection. tab le 1 shows relations between data width and number of check bits. table 1. sec-ded code - number of check bits needed data width number of check bits 16 6 32 7 64 8
ecc on spc560x microcontroller family AN4276 6/21 docid024408 rev 2 2 ecc on spc560x microcontroller family spc560x microcontroller family implements ecc mechanism for all its memories, ram, code flash and data flash. each memory has its own ecc block that calculates parity bits with each write access and checks data validity with each read access where 1-bit correction is done automatically if needed. decode result is reported out of the ecc module and collected in ecsm module and in parallel in flash modules for flash ecc errors. general scheme is shown in figure 1 . figure 1. ecc block scheme 2.1 ram ecc implementation data are protected on 32-bit word boundaries with seven check bits. it means that 39-bits are stored on write access and checked on read access. 7-bit check bits are calculated for whole 32-bits that have consequence for 8 or 16-bit accesses where the content of the requested address is read and checked first then merged with modified bytes, then ecc is calculated for whole 32-bit word and written back to memory. from that reason of read-modify-write operations, access time can vary depending on current and previous operation as shown in tab le 2 . encoder decoder wdata m-bits syndrome k-bits rdata_d m-bits rdata m-bits bit correction muxing ram read-modify-write m-bits system bus wdata_mem m+k bits rdata _mem m+k bits memory bus ecc block ecsm module table 2. sram timing current operation previous operation number of wait states required read idle / pipelined read 1 8/16/32 bit write 0 (same address) 1 (different address)
docid024408 rev 2 7/21 AN4276 ecc on spc560x microcontroller family ecc block has impact on sram initialization after power-up or destructive resets where ecc check bits may not correspond to data content and has to be recalculated. it means that whole memory must be written with 32-bit write accesses. otherwise read access to ecc non-initialized area will trigger ecc exceptions. 2.2 code and data flash memory ecc implementation differently from ram, flash memories are protected on 64-bit word boundaries with eight check bits. because of the nature of the flash memory that enables programming memory bits only in one direction from logical one to logical zero whole 64-bits should be programmed at once. reprogramming same word with different value may lead to different ecc check bit pattern that would cause reprogramming error. such limitation of bit reprogramming in the same location widely used in eeprom emulation can be a problem. therefore ecc scheme implemented in flash memories is slightly modified to support such features but in a limited manner. there are few data patterns selected from the whole set of available codes that do not lead to change of ecc check bit vector, see ta ble 3 . using such words can be used in eeprom emulation software to change status of data sets or sector status information in the same address location. each flash module contains status bits reflecting ecc check result for each read access. ecc hardware sets these bits whenever there is an ecc error. they are cleared from application software. seeing status bit set means that there was an error in one of the read memory accesses occurring between last and current status bit check. pipelined read read 0 8/16/ bit write idle / read 1 pipelined 8/16 bit write 32 bit write 2 8/16 bit write 0 (same address) pipelined 8/16/32 bit write 8/16/32 bit write 0 32 bit write idle / 32 bit write / read 0 table 2. sram timing (continued) current operation previous operation number of wait states required table 3. flash codes with the same syndrome double word 0xffff_ffff_ffff_ffff 0xffff_ffff_ffff_0000 0xffff_ffff_0000_0000 0xffff_0000_0000_0000 0x0000_0000_0000_0000
ecc on spc560x microcontroller family AN4276 8/21 docid024408 rev 2 2.3 ecsm module a part of error correction status module is dedicated to collecting ecc information reported by memories and underlying bus system. it provides set of registers storing extended information about last ecc fault signaled by status register esr. ecsm module differentiates between ram and flash memories, where code and data flash memories are merged and signaled as one flash ecc fault. code analyzing from which memory the fault comes has to use fear register storing the address and to bind it to the correct flash region. table 4. ecsm module register set register description register description ecr ecc configuration fedr flash ecc data esr ecc status rear ram ecc address eegr ecc error generation resr ram ecc syndrome fear flash ecc address remr ram ecc master femr flash ecc master number reat ram ecc attributes feat flash ecc attributes redr ram ecc data
docid024408 rev 2 9/21 AN4276 ecc error hardware exceptions 3 ecc error hardware exceptions there are two types of ecc fault notifications that are generated by hardware of spc650x microcontroller. ? ecsm module interrupts ? exceptions events of the core 3.1 ecsm module interrupts ecsm module interrupt can be generated in the case of both kinds of ecc faults, 1-bit and 2-bit, and they are further distinguished for ram and flash memory. this interrupt belongs among external peripheral interrupts that are linked to ivor4 vector. figure 2 shows block scheme of ecsm interrupt routing in the microcontroller. all interrupts that can be generated by ecsm module are configurable and can be masked by the user in ecr register. figure 2. ecsm interrupt generation 3.2 core exceptions in all cases, non-correctable ecc errors that occur during instruction fetch or data read cause generation of core exceptions because of bus transaction errors between z0 core and given memory target. core exception events cannot be masked and should be handled properly to solve the issue. several exceptions can be generated based on type of memory access, instruction fetch or data fetch, and configuration of machine state register msr, see ta ble 5 . single bit interrupts does not generate core exceptions, they can be caught by enabled ecsm interrupts. not all non-correctable ecc errors are signaled by core exceptions like ecc error during discarded not taken branch fetch, but they are signaled by ecsm module. ecc config reg ecc status reg & ecc catch registers intc module ivor4 vector external interrupt to z0 core z0 core ecsm module 1-bit ecc fault non-correctable ecc fault 1-bit ecc fault non-correctable ecc fault ram memory cflash / dflash memory interrupt handler
ecc error hardware exceptions AN4276 10/21 docid024408 rev 2 from the tab le 5 it is visible that ecc core exception system provides three priority notification levels. application has several trials to overcome the ecc error if it is possible. figure 3 shows an example of such exception flow. figure 3. example of core exception flow table 5. non-correctable ecc exceptions msr register bits access type result / exception ee me 0 0 instruction or data enter checkstop state 0 1 instruction or data ivor1 (machine check interrupt) 1 x data ivor2 (data storage interrupt) 1 x instruction ivor3 (instruction storage interrupt) running application msr.ee = 1 msr.me = 1 ivor2 interrupt handler msr.ee = 0 msr.me = 1 ecc non-correctable error data storage ivor1 interrupt handler msr.ee = 0 msr.me = 0 ecc non-correctable error instruction storage ecc non-correctable error instruction storage checkstop state reset (default setting in reset module) standard non-faulty application operations (like reading data from the flash memory) ecc error obtained during data read from the flash memory (first level of ecc handling, similar to standard external interrupt hanling in this case) more severe ecc error occurred during instruction fetch (application tries to recover , like safe termination of the system) another ecc error during instruction fetch in ivor 1 handler puts microcontroller to checkstop state where microcontroller does not know what to do, therefore stops. entering checkstop state leads to reset signal generation on spc560x microcontrollers (reset configuration of reset module)
docid024408 rev 2 11/21 AN4276 ecc exception handling 4 ecc exception handling as seen above, microcontroller always generates one of the exceptions for non-correctable ecc errors depending on the ee and me bits setting in the msr register. proper software handlers should be placed on ivor2, ivor3 and ivor1 exception vectors. z0 core used on spc560x microcontrollers adds additional complexity to the exception handling mixing several different exception causes to one vector, which means that software handler has to find the reason of the interrupt first. ivor2 and ivor3 exceptions merge following causes ? ecc non-correctable errors (ivor2 and ivor3) ? mpu access faults (ivor2 and ivor3) ? register protection violation (ivor2) general software flow of the exception handler ivor2 and ivor3 with focus on ecc processing is shown in figure 4 . ivor1 can differ in a way that having this exception (machine check) means that system recovery is hardly possible and system should safely terminate. figure 4. general ivor2/3 handler software flow ivor 2/3 handler start read ecsm.esr register rnce or fnce return back and continue to check other exception reasons ram or flash memory read ecsm.fear register code or data flash return back and finish exception handler. clear ecsm.fnce flag clear ecsm.rnce flag no yes flash ram code data take appropriate code flash ecc error action (most probably safe system termination) take appropriate data flash ecc error action. (most probably report this error and continue in system operations) take appropriate ram ecc error action. (most probably safe system termination in case of fault in used ram area)
ecc exception handling AN4276 12/21 docid024408 rev 2 4.1 ram ecc error action it is up to the system requirements what to do in case of non-correctable ecc error during read access to ram memory. handler can decide upon analysis of additional ecsm registers, like ecsm.rear register determining ram address. if the application considers such event as critical it is up to the application to terminate the system in the managed way. to clear non-correctable ecc error in the memory means to overwrite whole 32-bit word of affected ram cell with a new value that refreshes data and ecc value. 4.2 code flash ecc error action criticality of non-correctable ecc error from code flash memory depends on type of the access. error during the instruction fetch represents critical situation and can be taken as critical event requiring system termination. ecc error during data access can or cannot represent critical event depending on system implementation, like data redundancy etc. in such case error action depends on system design. 4.3 data flash ecc error action non-correctable ecc exception coming from data flash accesses can happen regularly and may not represent critical events especially when data flash memory is used for eeprom emulation. in such case it is desired to continue the program operation and let application software to solve the ecc data error. in principle there are two scenarios how error handler, ivor2 in this case, can let application software to continue its flow. ? continue with successive instruction of the read function ? continue from known address in the read function both scenarios are based on srr0 register modification which changes effective address where to continue once the handler returns back by rfi instruction. modification of srr0 register is necessary because it is loaded by effective address of the instruction that caused the exception, which means that using the original value of srr0 would cause execution of the same instruction accessing corrupted memory cell once returning from the handler. 4.3.1 continue with successive instruction of the read function target is to continue with the instruction that follows the instruction reading the data from flash memory like in figure 5 .
docid024408 rev 2 13/21 AN4276 ecc exception handling figure 5. pseudo-code for next instruction handler flow because of variable length instruction encoding, handler has to decode the length of the instruction on the address stored in srr0 register. it is done by means of analyzing opcode of the instruction that can reveal the actual length, 16 or 32-bit. once the length is known value of srr0 will be increased by the computed length. algorithm to find the instruction length for z0 core is shown in figure 6 , where first six bits of the first byte represents a primary opcode. bits are in big endian form, where the bit 0 in the leftmost bit in the word. figure 6. instruction primary opcode decoding next instruction decoding approach has an advantage that it returns exactly to next instruction in the application function which caused the ecc error regardless which function caused the error. later in the function code can be check of data validity. disadvantage can be processing time and exception load if for example function reads multiple data bytes in the loop and checks for the error after that. such loop will generate ecc exception for each read where the data are corrupted. 4.3.2 continue from known address in the read function it is similar to the previous approach of next instruction decode, but return from the error handler is to a known symbol in the function that can cause the ecc data access fault without need of instruction decode like in figure 7 . application function fce1() value = readdataflashword(addr) buffer[i] = storevalue endoffunction z0 core stores srr0/srr1 start of handler execution reason found decode address of next instruction (&storevalue) and move it to srr0 clear the ecc error flag finish handler (rfi) z0 core restores msr (srr1) and load pc counter with value of srr0 ivor2 exception (ecc on data flash access) instruction = read content of address given by srr0 reg instruction bit 3 srr0 = srr0 + 2 instruction bit 0 srr0 = srr0 + 4 ?0? ?1? ?1? ?0? 16-bit instruction 32-bit instruction
ecc exception handling AN4276 14/21 docid024408 rev 2 figure 7. pseudo code for known address jump an advantage of this approach is that ecc error is immediately found and possible read accesses stopped. this can save some time and exception load when reading long buffers without immediate error check. the disadvantage is that there must be only one function that can cause ecc error. it means that in whole application there is just one place where data flash is read. it is strongly dependent on software implementation. 4.4 clearing error flags ecc error flags in the ecsm module should be cleared for recoverable scenarios in order to enable proper exception handling for other causes, like register protection etc. other reason for clearing ecsm status bits is the property of the ecsm behavior where new ecc error overwrites the old information, because there is only one set of registers storing extended information. the recommendation is to clear these flags always, even in the case of non- recoverable situations. application function fce1() value = readdataflashword(addr) buffer[i] = storevalue endoffunction z0 core stores srr0/srr1 start of handler execution reason found move ecc_error_check symbol to srr0 register clear the ecc error flag finish handler (rfi) z0 core restores msr (srr1) and load pc counter with value of srr0 ivor2 exception (ecc on data flash access) ecc_error_check:
docid024408 rev 2 15/21 AN4276 application software notes 5 application software notes this chapter discusses some application aspects and areas that are linked to ecc protection mechanism implemented on spc560x microcontrollers. 5.1 ram memory checks sec-ded ecc mechanism provides meaningful protection against soft errors. but to use benefits of the ecc protection application support is needed. the list bellow shows the main points. ? configure ecsm module to report 1-bit ram ecc errors ? enable interrupt handling from ecsm module ? read regularly content of the ram memory, that triggers ecc check ? correct any single bit error caught by ecc in the interrupt each 1-bit ecc error in the ram memory shall be caught and corrected by the application. the reason is to prevent accumulation of several 1-bit errors that can lead to non- correctable error with potential undesired system shutdown. corrective action is based on writing back the corrected data value to the affected address. needed information is stored in ecsm registers, where affected address cell is given by rear register and corrected value by redr register. important thing is that ecc module does not check memory content automatically, but has to be activated by explicit read accesses. there are several possible approaches like reading the memory content piece by piece from the software function or using dma channel to scan the memory on background. method selected depends on system requirements and hardware features on particular spc560x microcontrollers. 5.2 operating system (os) exception handling whenever operating system is used it usually contains predefined exception handling implementation for most of exception vectors for given family of microcontrollers. example can be handlers for external interrupts coming from system timer, system call handler or memory protection handlers if memory protection is supported by the microcontroller. care must be taken when microcontroller has more exception events assigned to shared vectors like in case of ecc, register protection and memory protection on spc560x microcontroller family and not all are served by the os handler. in such case standard os handlers should give the user support to provide its own implementation and prioritization for these additional exception causes. ecc errors are of particular importance here. figure 8 shows an example of such scheme.
application software notes AN4276 16/21 docid024408 rev 2 figure 8. os exception handling with user hook 5.3 flash memory drivers flash driver can easily find if data read from the memory are correct or there was a non- correctable ecc error by reading flash module control register mcr. there are two status bits linked to ecc events, mcr.edc bit signaling single bit correction and mcr.eer bit signaling presence of non-correctable ec error during read operation. it is up to the driver and application how it processes these events. in any case, low level exception events are enabled and activated whenever there is a non- correctable ec error during read access. it can have impact on processing time needed to read the data from flash memory by the driver. driver should not rely on ecsm ecc status bits that are used and controlled in low level exception handlers and which are completely independent from the flash driver. there are several methods to read multiple data with ecc checking where each method has its pros and cons. ? check ecc immediately after each read access ? check ecc after whole data buffer is read ? low level exception handler linked to the driver ecc check ivor2 exception ie . -ecc -mpu - register protection os ivor2 handler() user ivor2 handler() ecc errors try to correct the ecc issue user ivor2 handler() call shutdown return usersolved value shutdown other reason of user interest return usernotsolved value yes no no usersolved continue with standard os handler yes no yes no
docid024408 rev 2 17/21 AN4276 application software notes 5.3.1 check ecc immediately after each read access figure 9. example of immediate ecc check during read function advantage recognition of corrupted data in the flash memory is immediate after the first read access. it can help to decrease time in the case where a lot of memory words are corrupted, like power drop during sector erase operation. disadvantage ecc check needs some processing time for each read access. this increases processing time of read operation in general. 5.3.2 check ecc after whole data buffer is read figure 10. example of ecc check after whole buffer is read advantage standard read buffer operation is not delayed with ecc check after each read access. this gives the standard performance in case of good memory sector. readbuffer () error = 0; for (i=0; i < length ; ++i) { buffer [i] = *( mem_ptr + i); if (mcr .eer == 1) { error = 1; break ; } } if (error ) { doerroraction (); end funciton ; } ... ivor 2 handler if (ecsm.fnce) { if (dataflash == true) { srr 0 <= change to next instruction ; return from handler ; } } 1x time readbuffer () error = 0; for (i=0; i < length ; ++i) { buffer [i ] = *( mem_ ptr + i); } if (mcr .eer) { doerroraction (); end funciton ; } ... ivor 2 handler if (ecsm.fnce) { if (dataflash == true) { srr 0 <= change to next instruction ; return from handler ; } } i times
application software notes AN4276 18/21 docid024408 rev 2 disadvantage any read access with ecc error generates low level exception that runs on background so many times as there are items in the loop. it can have impact on time needed for initial read of a sector with many corrupted cells. 5.3.3 low level exception handler link to the driver ecc check figure 11. example of low level link to the driver ecc check advantage in case of an ecc error during read access, code execution of read function immediately moves to ecc check part, which should find that the data are corrupted. there is the same performance during errorless operation as well as with ecc errors. disadvantage because of using exported symbol in the low level exception handler, this symbol should be unique in the whole application. it means that there is only one place in the application and the driver that read from the flash memory. readbuffer () error = 0; for (i=0 ; i < length ; ++i ) { buffer [i] = *( mem_ ptr + i); } ecc_check : if (mcr. eer) { doerroraction (); end funciton ; } ... ivor 2 handler if ( ecsm. fnce) { if (dataflash == true ) { srr 0 <= change address to ecc _check symbol ; return from handler ; } } 1x time
docid024408 rev 2 19/21 AN4276 document references appendix a document references 1. spc560d30l1, spc560d30l3, spc560d40l1, spc560d40l3 32-bit mcu family built on the embedded power architecture ? (rm0045, docid16886) 2. spc560b40x, spc560b50x, spc560c40x, spc560c50x 32-bit mcu family built on the embedded power architecture ? (rm0017, docid14629) 3. support microcontrollers spc560b54x, spc560b60x and spc560b64x (rm0037, docid15700) 4. spc564bxx, spc56ecxx 32-bit mcu family built on the embedded power architecture ? (rm0070, docid18196) 5. spc560p34/spc560p40 32-bit mcu family built on the embedded power architecture ? (rm0046, docid16912) 6. 32-bit mcu family built on the power architecture ? embedded category for automotive chassis and safety electronics applications (rm0022, docid14891) 7. 32-bit mcu family built on the power architecture ? embedded category for automotive chassis and safety electronics applications (rm0083, docid018714) 8. error detecting and error correcting codes ? hamming, the bell technical journal 1950
revision history AN4276 20/21 docid024408 rev 2 revision history table 6. document revision history date revision changes 21-mar-2013 1 initial release. 18-sep-2013 2 updated disclaimer.
docid024408 rev 2 21/21 AN4276 please read carefully: information in this document is provided solely in connection with st products. stmicroelectronics nv and its subsidiaries (?st ?) reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described he rein at any time, without notice. all st products are sold pursuant to st?s terms and conditions of sale. purchasers are solely responsible for the choice, selection and use of the st products and services described herein, and st as sumes no liability whatsoever relating to the choice, selection or use of the st products and services described herein. no license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. i f any part of this document refers to any third party products or services it shall not be deemed a license grant by st for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoev er of such third party products or services or any intellectual property contained therein. unless otherwise set forth in st?s terms and conditions of sale st disclaims any express or implied warranty with respect to the use and/or sale of st products including without limitation implied warranties of merchantability, fitness for a particular purpose (and their equivalents under the laws of any jurisdiction), or infringement of any patent, copyright or other intellectual property right. st products are not designed or authorized for use in: (a) safety critical applications such as life supporting, active implanted devices or systems with product functional safety requirements; (b) aeronautic applications; (c) automotive applications or environments, and/or (d) aerospace applications or environments. where st products are not designed for such use, the purchaser shall use products at purchaser?s sole risk, even if st has been informed in writing of such usage, unless a product is expressly designated by st as being intended for ?automotive, automotive safety or medical? industry domains according to st product design specifications. products formally escc, qml or jan qualified are deemed suitable for use in aerospace by the corresponding governmental agency. resale of st products with provisions different from the statem ents and/or technical features set forth in this document shall immediately void any warranty granted by st for the st product or service described herein and shall not create or extend in any manner whatsoev er, any liability of st. st and the st logo are trademarks or register ed trademarks of st in various countries. information in this document supersedes and replaces all information previously supplied. the st logo is a registered trademark of stmicroelectronics. all other names are the property of their respective owners. ? 2013 stmicroelectronics - all rights reserved stmicroelectronics group of companies australia - belgium - brazil - canada - china - czech republic - finland - france - germany - hong kong - india - israel - ital y - japan - malaysia - malta - morocco - philippines - singapore - spain - swed en - switzerland - united kingdom - united states of america www.st.com

▲Up To Search▲

Price & Availability of AN4276

	To Download AN4276 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .